Not sure if I see the need for this change. You always have to pass in a patch which corresponds to the base. If it's an incorrect patch you can then get garbage data even if err == nil. It's truly is an exceptional case if you pass in mismatching patches + data. Not sure if it's worth paying the cost of additional bounds checking and error passing instead of just recovering from the panics like this:

func (options *Options) ApplyPatchRecovery(root interface{}, patch Patch) (res interface{}, err error) {
  defer func() {
    if r := recover(); r != nil {
      err = fmt.Errorf("panic recovered: %v", r)
    }
  }()
  res = options.ApplyPatch(root, patch)
}

That seems less clean to me considering (1) panics are slow in Go compared to normal errors, as they need to unwind the stack, and (2) panics are not specific to mismatches. This is intended to handle the specific error we are seeing in production. Panics can still happen for other reasons than mismatch (i.e. actual code bugs).